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Abstract: VERITAS, the Very Energetic Radiation Imaging Telescope Array System, is an array of four 
12 m diameter imaging atmospheric Cherenkov telescopes for gamma- ray astronomy above 100 GeV 
currently in operation in Arizona. The VERITAS Collaboration has developed VEGAS, the VERITAS 
Gamma-ray Analysis Suite, a data-analysis software package for the processing of single- and multiple- 
telescope data produced by the array. The package consists of a core of six stages as well as visualisation 
and diagnostic components. It has been developed in C++ using modern objected-oriented design pat- 
terns to be highly flexible, configurable and extendable. VEGAS utilises CERN's ROOT data-analysis 
framework and runs on Linux and Mac OS X systems. The architecture and structure of the VEGAS 
package will be described in detail while the data analysis algorithms are described in additional papers. 



Introduction 

The VERITAS [16] Collaboration instituted a 
working group in late 2005 to design, create 
and maintain a complete offline analysis pack- 
age for the reduction of VERITAS data. This 
group, named the Offline Analysis Working Group 
(OAWG), comprises collaborators from several of 
the VERITAS institutions. Following a series of 
meetings at various institutions in Ireland, Canada 
and the U.S., the OAWG released the first ver- 
sion of the package VEGAS in early 2007. The 
OAWG has continued to release upgrades and ex- 
panded versions of the package on a regular basis. 
This paper gives an overall summary of the many 
components of VEGAS including analysis stages, 
architecture, documentation, organisation and per- 
formance. 

Analysis Stages 

There are six stages in the VEGAS analysis 
paradigm as outlined in Table 1 . In the first stage 
calibration parameters such as pedestals and rela- 
tive gains are calculated. The VERITAS database 
(implemented in MySQL[5]) is queried for run- 
specific information such as high voltage records, 



tracking information and target information. These 
data are stored in a customised binary output for- 
mat generated using the CERN ROOT [2] library. 

In the second stage of the analysis the FADC traces 
are evaluated[9]. This includes pedestal subtrac- 
tion and relative gain and timing correction. For 
each data channel in each event, a data class con- 
taining the integrated charge, integration parame- 
ters and other channel parameters are stored. The 
data are saved to the same binary file. 

In the third analysis stage, the data are cleaned [10] 
using an advanced form of the Picture/Boundary 
cleaning method. Following this the data are pa- 
rameterised for both a 1-D and a 2-D analysis ac- 
cording to the Hillas [12] moment technique. 

In the fourth analysis stage, stereo reconstruction 
is applied (if the data involves more than one tele- 
scope). Cuts are applied to determine whether the 
image from a particular telescope is of sufficient 
quality to contribute to the stereo parameterisation. 
Shower origin in the sky and shower core loca- 
tion on the ground are determined. These are used 
in conjunction with Monte Carlo simulations of 
gamma-ray air showers to calculate mean scaled- 
width, mean scaled-length and an energy for each 
event [10]. 
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In the fifth analysis stage, background rejection 
is performed. This is done primarily using cuts 
on mean-scaled width and length, although cuts 
on other parameters such as time can also be ap- 
plied. Stage 5 has the ability to cut on multiple data 
types including single telescope Hillas parameters, 
stereo parameters or a combination of both. 

The sixth analysis stage performs background es- 
timation in various observing modes for both 1-D 
and 2-D analysis. The reflected-region background 
model and ring -background models [10] have been 
implemented. The probability of detection of an 
observed target is calculated using the Li&Ma [14] 
formalism, and where a sufficiently strong detec- 
tion is made, a spectrum can be determined. 

Architecture 

Modularity is one of the primary VEGAS design 
goals. This means that for any given algorithm, 
for which there could be several implementations, 
it must be simple to substitute one implementa- 
tion for another. This is accomplished using the 
object-oriented language C++ with singleton in- 
stances of factory classes. A factory class selects 
the algorithm that is to be used based on the con- 
figuration specified, and the singleton pattern en- 
sures that only one factory class is generated for 
each algorithm. The use of factory classes means 
that function calls do not need to check which algo- 
rithm is being used each time the function is called. 
This leads to reduced analysis overhead and sim- 
pler code. 

Configuration 

Each analysis class can be configured from the 
command line or from a configuration file (or 
both). The configurable options for each class are 
set when the class is constructed. Users can eas- 
ily get a list of the configurable options available 
from the command line help. However, as all of the 
main programs have a very large number of config- 
urable options, it is often desirable to use a config- 
uration file. Each main program can automatically 
produce a configuration file indicating the default 
values of every configurable parameter. The user 
can then edit this configuration file and use it as a 



pilot file for the main program. Users can also eas- 
ily share configuration files, which in concert with 
the use of tagged releases of VEGAS, ensures that 
reproducible results can always be attained. The 
configuration is also written to the data file allow- 
ing the settings with which the analysis was run to 
be queried. 

Data Products 

All of the VEGAS data classes are constructed 
as ROOT TObjects, allowing reading and writing 
in an efficient manner with a standard interface. 
Within the ROOT file, output from each analysis 
stage is arranged into directories, with some out- 
put saved as single instances of the correspond- 
ing data class, and some output saved as ROOT 
TTrees. The TTree can store multiple instances of 
a data class, allowing large volumes of data to be 
read and written in an efficient manner. 

Macros and Visualisation 

The VEGAS data class definitons are compiled 
into a shared library which can be used to develop 
simple macros which run within the ROOT CINT 
interpreter. The output of such a macro is displayed 
in Figure 1, showing the PMT currents in each 
pixel at a particular time for a single telescope. 

A diagnostics program is also built using the 
ROOT library which displays reconstructed events 
in the camera, shower and mirror planes. This 
diagnostics program also displays the raw FADC 
data and demonstrates image cleaning, Hillas pa- 
rameterisation, and stereo reconstruction. There 
are also built-in macros for examining Monte Carlo 
simulations of air showers. 

Simulations 

Monte Carlo simulations [15] of gamma-ray and 
comic-ray air showers play a pivotal role in the 
analysis of Cherenkov telescope data. There are 
a variety of simulation channels available within 
the VERITAS collaboration including KASCADE 
[13], Corsika [11], GrISU [7] and ChiLA. The 
reading and writing of simulation data specific to 
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Stage 


Purpose 


Input(s) 


Output 


Time(m) 


Size(MB) 


1 


Calib. Calculation 


Raw Data 


Calibration Data 


8.2 


51 


2 


Calib. Application 


Raw + Calibration Data 


Calibrated Events 


39 


6200 


3 


Image Param. 


Calibrated Events 


Param'd Events 


14 


224 


4 


Shower Recon 


Param'd Events 


Recon'd Showers 


6 


40 


5 


Event Selection 


Recon'd Showers 


Selected Events 


< 2 


202 


6 


Results 


Selected Events 


Statistics & Figures 


< 1 


< 1 



Table 1: The VEGAS analysis chain with execution time (on a 2.66 GHz Apple XServe running OS X 
10.4.9) and output size (for a 5000MB input file). Note that 'Calib.', 'Param'd' and 'Recon'd' are abbrevi- 
ations of 'Calibration', 'Parameterised' and 'Reconstructed' respectively. 



each package is handled using package-specific 
data classes. Although simulations for VEGAS 
have primarily been performed using KASCADE, 
VEGAS is designed to be compatible with the 
other Monte Carlo codes so that systematic bias 
may be avoided, and simulations codes can be 
cross-checked. 

Documentation 

The VEGAS code is documented in several ways. 
At the lowest level, functions and classes are docu- 
mented using Doxygen [3]. Doxygen allows code 
and comments to be viewed in a hyperlinked for- 
mat using a standard web browser. The OAWG de- 
velopers can expand on the documentation, partic- 
ularly in relation to algorithms, using a customised 
Wiki [4]. The Wiki is a website that easily allows 
fast content editing - this is beneficial in the case 
where algorithms and methods are being continu- 
ously updated. Is it also used to coordinate meet- 
ings and consistency checks. Finally, an online 
users manual is maintained at a separate website. 
The online manual details compilation and instal- 
lation of dependencies and the code itself. Detailed 
instructions regarding running the code and inter- 
preting the output are also provided. 

Organisation and Communication 

The OAWG is organised through weekly telecon- 
ferences. This affords both developers and users 
the opportunity to discuss and query issues rele- 
vant to algorithms and analysis techniques. This 
is further facilitated by the use of two Electronic 



Logbooks (ELog) [1]. The first is the main OAWG 
ELog ; it is a forum where developers can dis- 
cuss and debate various analysis and coding issues. 
This has a proven to be a valuable resource as de- 
velopers can use it to keep track of changes while 
maintaining a long term archive of discussions per- 
taining to analysis and code design. The second 
ELog is a users forum which facilitates VEGAS 
users in asking questions regarding how to install 
and run VEGAS. 

Directory Structure 

Each main analysis stage has its own directory, 
containing class definitions, implementations, doc- 
umentation and examples. There is a common di- 
rectory containing classes and algorithms that are 
used by multiple analysis stages. These include 
most data classes, configuration classes and classes 
pertaining to I/O. There are also separate directo- 
ries for macros, utilities, diagnostics, documenta- 
tion and binaries. 

Code Management 

The VEGAS source code is stored in the main 
VERITAS CVS [6] repository. CVS is a version 
control system which allows several developers to 
concurrently work on the same code. It also allows 
old versions of the code to be easily retrieved. The 
CVS repository can be browsed in a hyperlined en- 
vrionment [8] facilitating the examination of code 
revisions. Code tagging is used to enable users 
and developers to download identical versions of 
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Figure 1: Macros used in the ROOT CINT com- 
mand line interpreter in conjunction with the VE- 
GAS shared library can be used to easily visualise 
data such as the PMT currents at a particular time. 



the code for testing. This ensures reproducability 
when users are cross-checking results. 

In order to ensure consistency and stability, the 
VEGAS code is released following beta-test cy- 
cles. When new analysis or coding features have 
matured, the current version of VEGAS on CVS 
is tagged. This tagged code undergoes a series of 
beta tests and cross checks in order to ensure sta- 
bility. One of the most important tests is ensur- 
ing that the code gives identical output on differ- 
ent platforms and architectures and with different 
compiler versions. Once a tag has been approved it 
is released to the VERITAS collaboration for gen- 
eral use. In the event that coding errors or other is- 
sues are found in the released version, it can be cor- 
rected as a separate CVS branch. This allows de- 
velopment of the current version to continue with- 
out delaying deployment of the corrected release. 

Performance 

VERITAS raw data is particularly large with ap- 
proximately 5 GB of data written for a typical 
run. These runs contain approximately 240,000 to 
260,000 events. The analysis times and output file 



sizes for each analysis stage (for a single 5GB run) 
are shown in Table 1 . As the output of stage two is 
particularly large, it can be discarded after running 
stage three resulting in more manageable file sizes. 

Future Plans 

Although a huge amount of development has al- 
ready taken place, there remains much to be done. 
The development of VEGAS will continue hand- 
in-hand with the development of new algorithms 
for stereo event reconstruction, background esti- 
mation, 2-dimensional analysis and spectral anal- 
ysis. 
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